Behavioral Patterns

• Definitions:

  • "Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects."

  • "Behavioral design patterns are design patterns that identify common communication patterns among objects. By doing so, these patterns increase flexibility in carrying out communication."

• Types of Behavioral Patterns .

• Types of Behavioral Patterns .

• Direct and Indirect Communication Patterns

• 

Strategy Pattern

• It is the Component Pattern, that is, 'dependency injection'.

• Creates an Interface with ('abstract methods' and 'virtual methods') (?).

• Uses Composition, since the 'class' does not inherit from anywhere, it only asks for components, where those components are 'concrete classes' of the Interface.

• Strategy Pattern .

  • He made use of Interfaces, which I did not understand the need for.

• Example of Strategy Pattern .

  • {16:58}

    • He shows that certain implementations of the Interface have duplicated code due to their similarity.

    • It is discussed how to solve the problem, but the idea is that "the solution to an Inheritance problem is not to add more Inheritance".

Observer Pattern

• It is the Signal Emission pattern.

• Observer Pattern .

  • At the end of the video the code is shown demonstrating the functions and relations between the Observable and Observer.

• Events and Signals in games .

  • {32:20}

    • He wraps up the reasoning well.

  • The use of signals is a good solution to separate objects that should not relate, but it is a bad solution when used on objects that should relate.

  • This all comes down to the question "what should be defined as an object and what should be defined as part of an object"? "where does your object begin and where does it end"?

State Pattern (State Machine)

• It is the State Machine pattern.

• A State Machine is nothing more than an 'if/else' or 'match', but for reasons of clarity and organization in a Component System style, states are extracted into different scripts, creating components that represent the States.

• My notes on the topic : Game AI .

  • Considering that a State Machine is normally used to define AI, it makes more sense for the notes to be there.

Template Method Pattern

• Template Method Pattern .

  • {41:53 -> 50:02} (only relevant part of the video)

• It is similar to the Strategy Pattern.

• Comparison between the Template Method Pattern and Strategy Pattern:

  • Template Method Pattern:

    • Creates an 'abstract class' with 'abstract methods' and 'virtual methods'.

    • Uses Inheritance, since the 'class' inherits from the 'abstract class'.

  • Strategy Pattern:

    • Creates an Interface with ('abstract methods' and 'virtual methods') (?).

    • Uses Composition, since the 'class' does not inherit from anywhere, it only asks for components, where those components are 'concrete classes' of the Interface.

• Considering this, the Template Method Pattern makes a larger assumption of immutability, assuming the system will never change, making it somewhat unsafe in many cases.

  • For reasons like this, I choose not to use State Machines. I believe State Machines are by their nature a form of Template, which makes me quite wary about the code structure.

  • I made several criticisms about this when analyzing State Machines.

• Chat GPT:

  • Template Method Pattern:

    • The Template Method pattern is intrinsically based on inheritance. It relies on the principle of a base class that defines the skeleton of an algorithm and allows subclasses to implement specific parts of that algorithm. Those specific parts are often implemented through abstract methods defined in the base class and implemented in subclasses. Therefore, inheritance is an essential part of implementing this design pattern.

  • Finite State Machines:

    • Implementing FSMs does not necessarily depend on inheritance. In many cases, states and transitions can be implemented without direct use of inheritance. Each state can be represented by a separate class, but that does not mean one class must inherit from another to represent different states. However, in some implementations it may be useful to use inheritance to share common behaviors between states, but this is not a strict requirement.

Null Object Pattern

• It is very simple. The idea is that in some cases a check 'if object != null' is always performed, but the proposal is to make the object always exist, so it can never be 'null'; instead it will be a generic object that implements the interface but simply does nothing.

• Null Object Pattern .

• Review :

  • Cool. Interesting.

  • It can be useful when an object uses Interface / Inheritance; otherwise the pattern is not applicable and does not make sense.

  • It is a nice way to remove the 'null' check using Subtype Polymorphism.

Command Pattern

• It is a pattern for creating 'programmable buttons', outsourcing the command, etc.

• The pattern is straightforward, but it definitely sounds like over-engineering for simple cases.

• Command Pattern .

  • The example given is a "smart home remote control, where the remote's functions can be programmed by the phone".

• Review :

  • Very specific for creating buttons and perhaps ~over-engineering.

Iterator Pattern

• Iterator Pattern .

  • Advantages:

    • "The collection does not have to expose its representation. Every time the collection is requested, one item of the collection will be given, without ever having to worry about or expose the 'shape' of that collection."

    • "There is always a pointer pointing to the next element of the iteration, so the iteration can stop at any time and continue from where it left off".

  • {59:54}

    • The UML diagram is shown, which helps to understand the relationship between Iterator and Iterable.

• Review :

  • Interesting, but quite specific.